The present approach to delivery of updates to client interfaces is inadequate for some client-server applications. For example, when an element of a served interface container (such as a Web page, XML document or other container structure) is invoked within a client container context, a server is prompted to provide a new interface container to update the client interface. A problem with such an approach to updating a client interface is that while regenerating an entire interface container may be satisfactory for presenting simple content, it is poorly suited for interactive applications, particularly where one or more elements of the interface container are unchanged between updates.
This problem and others may be better understood by considering a specific client-server interface example, such as the delivery of Web page updates to a Web browser client. Generally, when a hyper-link or other input to a browser client is invoked, the pertinent Web server receives a command to generate a complete Hyper-Text Markup Language (HTML) page. This HTML Web page is then delivered to the client and completely updated on the browser.
Traditional Approaches to Web Page Refreshing
The Internet was originally conceived of and developed as a virtual environment that electronically mimics scholarly journals, articles, books, and other real world paper-based media. In such a context, whole page replacement and updating (refreshing) makes sense and is even desirable, just as when reading a book, it is desirable to turn an entire page at a time, and not small sections of a page.
On the other hand, such a whole page refreshing-based paradigm makes little sense for traditional business software. In a software application, a user may change only one item at a time and this change may affect only two or three other items in the user interface, not the entire application surface. For example, to determine a value using a calculator (whether in the real world, or virtually, through software), most often the user types in an integer, depresses a function button, types in a second integer, depresses another function button, and then views the final value. In such a case it would make little sense for the entire surface of the calculator to disappear only to be redrawn again each time the user clicks a function button. The only data a user is interested in seeing change is the data located in the calculator's data entry field. Updating anything else is a waste of time and a visual annoyance. Unfortunately, just such a data update delivery method typically confronts Web-based software application users today.
Traditional Internet Client/Server Model
In the client/server model as it is traditionally applied on the Internet, the client consists of a computer hosting a Web browser where user interaction with the application takes place. The server is often a separate computer located elsewhere and forming a part of the Internet. In order to access the Internet, the server computer must have a Web server installed that makes communication across a network, such as the Internet, possible. Web servers contain Web pages that they “serve” or make available to any client that connects to them using an appropriate Internet communications protocol. The most common Internet communications protocol is the Hyper Text Transport Protocol (HTTP).
Often Web servers act as middleware (software that enables communications between two other distinct pieces of software) to connect the user interface on the browser to another server piece (located “behind” the Web server) where the processing for a Web application occurs. The application server provides the back-end processing of the application. A user interacts with a Web-based application through a user interface displayed on the browser. This “back-end” server is where the “business logic” of a Web-based application is processed.
In addition to communicating with the browser through the Web server, the server side of a Web-based application may itself also function as middleware as it communicates with still other middleware data or applications, and to other back-end services such as Simple Object Access Protocol (SOAP) services, Web services, database services, or “legacy” applications (applications that are not themselves Web-enabled). SOAP services encode the information in Web service request and response messages before sending them over a network. Web services are a standardized way of integrating Web-based applications using the Extensible Markup Language (XML), SOAP, Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI) open standards over an Internet protocol backbone.
State and Stateless Issues
Any kind of back-end component has a certain state at any given moment. Data that exists in such a back-end component does so in a certain condition and has arrived at that condition due to various changes and computations achieved in part from user input. The Internet is intrinsically stateless because each request for a new Web page is processed without any memory of previous pages requested. The protocols that enable Internet communications are stateless. It is because of this stateless nature that Web pages traditionally require a whole page refresh to portray state changes on the server. This is one of the chief drawbacks to the HTTP protocol. The ability to manage and propagate state throughout an application session is what gives desktop applications their power. Because maintaining state is extremely useful, programmers have developed a number of techniques to add state to the World Wide Web environment. These include server Application Programming Interfaces (APIs), such as Netscape Application Programming Interface (NSAPI) and Internet Server Application Programming Interface (ISAPI), and the use of “cookies.”
When a Web browser or another process experiences input that affects state on the server for its related application, there needs to be a way to communicate server state changes to appropriate locations in the application interface on the browser. Traditionally, these state changes demand whole page updating of the browser because while both the client and the server are “stateful,” the protocols most often used to communicate between the client and server are “stateless”—that is such protocols can only request a new Web page to be delivered to the client. Stateless protocols cannot convey information about all the changes that have been made on the browser throughout the application session up to that point. This inability to keep track of the past and current states (conditions) in the application means that a Web application developer who wants the ability to track state throughout the life of an application is left wanting.
Today, many of the most widely used Internet applications are those which depend upon backend database storage and retrieval. The methodologies for retrieving and storing database queries are themselves inherently stateless. This results in a situation where both the backend service and the application interface lack the ability to maintain state. Current middleware solutions can tend to act as a transparent “pass through” of stateless getting and setting of data. The problem with such an approach is that for more powerful applications using multiple back end resources, tracking the state of a given data element may be very important to the proper functioning of the entire application. Unfortunately, current techniques are not adequate to this challenge.
For example, because traditional database query models are “unaware” of the scope of change created by isolated user input, even a single change on most form-based Web applications requires a new query of the database and a subsequent whole page update when the database query is returned by the server. There is no mechanism in place to verify a need for a database query in the first place, and certainly no way to update only those areas affected by that single change. Stateless protocols do not provide a method for tracking the state of individual portions of data located on a given Web application interface.